Computers are used all over the world to perform a wide variety of tasks. Computers perform these tasks by executing software code. Software code is typically written by one or more software developers using some type of integrated development environment (IDE). In many cases, developers are given a set of design instructions, and, using a programming language, draft software code that will implement the functions described in the design specifications. Depending on the nature and scope of the design specifications (or any subsequent modifications thereto), code for the software program can often become lengthy and complex. Complex code often leads to an increase in software bugs.
One method commonly used to decrease the likelihood of having bugs in the software code is known as test driven development (TDD). In TDD, a developer effectively breaks down a much larger program into smaller sections of functionality, often referred to as units. Each unit is testable by itself and typically only incorporates a single code function. For example, if a developer were writing a program designed to send email, the developer would break down the ultimate task—sending an email—into multiple subportions. These subportions would again be broken down until each unit involved only a single function. Once the function is identified, the developer typically writes software code specifically designed to test the unit with the identified function. Such code is usually called a “unit test.”
The next step in TDD is to run the unit test and verify that the existing code for the tested unit (i.e. “unit code”) fails the unit test. A failure is expected at this point in the TDD methodology by design to verify that the unit test actually verifies the functionality. Once the unit code fails the unit test, the developer knows the unit test is working properly and can begin revising the unit code so that it will eventually pass the unit test. Code revisions are typically minimal in nature with an overall goal of simplicity and efficiency. The resulting code tends to have fewer bugs. In the broad sense, if each unit works properly on its own, the chances are much better that when the units are combined, they will produce the desired functionality (e.g., sending an email). Once the developer has made enough revisions to the unit code so that it passes the unit test, the developer identifies the next unit of functionality and drafts a unit test to assess the functionality of that unit. This process repeats until all identified functions have passed the unit tests and may then be tested in combination to verify that the units work with each other.
However, this TDD approach, sometimes referred to as an element of “Extreme Programming,” is not always the most efficient. Each unit to be tested must first be identified. This leaves open the possibility that the developer may overlook one or more important portions of functionality that should be incorporated into the program. Furthermore, unit tests are only designed to test a single code unit. Thus, developers using TDD are continually drafting new unit tests for each new piece of functionality. This process is often quite tedious and relies heavily on the developer's skill. If the unit test itself has been improperly coded or has simply been forgotten, the unit will not be properly tested. The unit may thus appear to pass, when in reality, it is working incorrectly. Thus, while aiding in reducing bugs, TDD relies heavily on the as developer to develop bug-free code.